Subject: AIW 10 - DLSw RIG Minutes

From: Paul Brittain <[email-masked]>
Date: Tue, 16 Jul 1996 11:18:15 +0100

Here are the minutes of the DLSw RIG sessions at AIW 10.  

The topics discussed were:

-	clarifications to RFC 1795
-	Scalability enhancements
-	other work items
-	timescales and versions.

Clarifications to RFC 1795:
===================

The cumulative list of areas requiring clarification were identified
(including those first discussed at AIW 9) is as listed below.

-	It is not permitted for a DLSw implementation to check that the send
port used by a partner is 2067.  All implementations must accept
connections from partners that do not use this port.

-	If a DLSw does not support any of the options on a CAP-ex, or thinks
the cap-ex is malformed, it must send a CAP-ex negative response.  The
receiver of a cap-ex negative response is responsible for dropping the
connection.  It is not permitted to drop the link instead of sending a
CAP-ex negative response.

-	All implementations must quietly ignore unrecognized control vectors.

-	The RII bit in MAC addresses received from the LAN must be set to zero
before forwarding in a SSP message.  This requirement aims to avoid
ambiguity of circuit IDs.

-	The MAC header is included in forwarded SSP Netbios frames in the
format described in the minutes for AIW 9.

-	The Vendor ID field in a CAP-ex may be zero.  However, a zero Vendor
Context ID is not permitted, which implies that an implementation that
uses a zero ID cannot send any vendor-specific CVs (other than those
specified by other vendors that do have a non-zero ID)

-	The first flow-control ack (FCACK) does not have to be returned on the
REACH_ACK even if the ICR_cs carried the FCIND bit.  However it should
be returned on the first SSP frame flowing for that circuit after the
REACH_ACK.

-	LF-bits should be propagated from LAN to SSP to LAN (and back) as per
a bridge (i.e. they can only be revised downwards at each step if
required).

-	HALT reason codes should be added to the HALT_DL and HALT_DL_NOACK SSP
messages.

-	All implementations must allow for the partner DLSw varying the
Transport ID up to and including when the ICR_cs message flows, and at
all times reflect the most recent TID received from the partner in any
SSP messages sent.  The TID cannot vary once the ICR_cs message has
flowed.

-	The CUR_cs frame should only be sent when the DSAP is known. 
Specifically, CUR_ex should be used when a NULL XID is received that is
targeted at DSAP zero, and CUR_ex when a XID specifying the (non-zero)
DSAP is received.

-	Some clarification required to the text describing when and how to
drop to a single TCP pipe (see attached mail from Doug Wolff for further
details).

We concluded the introductory session with some discussion on how to
publish the work in progress.  Options considered were:

-	publishing a complete new 'merged' document
-	publishing the changes only
-	either option as a new RFC or as an update to the current RFC.

There was some worry that it is not possible to publish updates to an
informational RFC, and hence we should produce a completely separate
document.  This should include the scalability proposal, whatever else
is added, and the list of clarifications to the current RFC.

Scalability Proposal:
===============

Most of the time at AIW 9 was spent discussing the scalability proposal.
 This lengthy series of discussions came up with a number of major
points, and some more minor editorial issues.  The editorial points have
not been listed in full here for sake of brevity.  Dave Bryant has
already posted the updated scalability document.

The issues identified and their resolution were as described below

-	The background covered in section 1,2 and 3 should remain in the
document

-	Section 5 should become part of section 4

-	Section 2 will need changing to incorporate other work in the RIG (see
below).  This activity will be deferred to the CP draft for closure once
the full set of work forming the next version is complete.

-	Section 3 should be modified to allow for non-IP transports, but this
document will describe only IP

-	Add a CAP-ex vector to allow disabling of the use of the multicast
scalability enhancements (though all "v2 compliant" implementations must
be capable of using the multicast enhancements).

-	The client/server group discussion is to be removed from the document
and replaced with a single default multicast address.  

-	There is a worry that use of multicast may negate the value of the
Netbios Name List that currently flows on a CAP-ex. 

-	Ravi (CISCO) was concerned that there may be other fields in the
current SSP formats that are impacted by multicast.  This should be
discussed at AIW 11.  

-	We need to identify the UDP port to be used (Choon Lee posted a
submission on this since AIW 9)

-	Unrecognized frames or CVs received via UDP must be quietly ignored.

-	Dave Bryant to find out how to reserve a set of multicast addresses
for use by the AIW.

-	Add flow diagrams for SNA and Netbios circuit setup and drop the
pseudo code.

-	It was decided that we should not pass multicast listening addresses
to DLSw partners.

-	Section 8.2 should encourage use of TCP for CUR-ex verification if a
pip is already up, otherwise Unicast should be used.  Also, clarify that
it may be necessary to send multicast to and TCP explorer frames in the
migration case.

-	Section 8.4.1 should be reworded to make the retry timers an
implementation option.  However, retries of UDP responses should not be
sent.

-	Define unicast (= UDP or TCP to a specific IP address), multicast and
downlevel up front.

-	Section 9 (Netbios) should allow Unicast in place of Multicast where
the sending DLSw can resolve the destination to a single partner.

-	Note 3 under the table in section 9 should not include the reference
to a new packet format, which is not required.

-	Rewrite section 9.3 as a retry column in the table in 9.0.

-	Add the CAP-ex option to turn off multicast to section 11.

-	Section 12 should use RFC 1795 frame formats.

Other work:
=========

The following additional points came up during the scalability
discussion.

-	There is considerable interest in use UDP unicast as well as
multicast.  Frank Bordonaro has posted a proposal for this, and we must
discuss at AIW 11 how to integrate this with the current working
document (I have not had time to do this since Dave posted his updated
document owing to moving house). 

-	The issue of reducing the SSP frame header size for Netbios frames was
raised, but postponed for future work.  Proposals are welcomed on this
topic.

-	HPR (i.e. RTP) can use two SSAP/DSAP pairs and UI frames on SNA
circuits.  The current RFC and the scalability proposal do not address
the transport of RTP.  Proposals are welcomed on this topic.

-	We discussed a vendor-specific SSP frame format as follows:

	Byte 0:		Version number (x32)
	Byte 1:		header length
	Byte 2-3:	message length
	Byte 4-6:	vendor OUI (x000000 reserved for AIW use)

	Currently the AIW has no planned use for this new frame format, but it
should be documented in the next version of DLSw.

Timelines and versions:
=================

The RIG concluded with a discussion of the content of the next version
of DLSw.  This actually identified a core set of function that will be
released as version 1.1 (rather than 2.0) of the standard that is
targeted for CP at AIW 12.  Items for possible inclusion on later
versions were also identified, but no timescale was set for versions
beyond v1.1.

1.1 functions:

-	Scalability (Dave's proposal - already posted)
-	UDP/unicast (Frank to submit - already posted)
-	Smaller headers (Ravi to submit)
-	1795 clarifications
-	resource addressing over non-TCP transports (John to submit)
-	vendor-specific SSP format

1.2 functions:

-	non-IP SSP transports (Ivan to submit)

Tentative v2 functions:

-	HPR support
-	Discovery support

Later:

-	loop prevention.

-------------------------------------------------------------------------
-----------------------
ATTACHMENTS:
=============

Paul - I offered to write some clarifications to the RFC about starting
tunnels
and single tunnel negotiation. It seems to me the modifications are
minor.

In section 3 (transport connections), I would modify the paragraph below
the
figure as follows:

   Each Data Link Switch will maintain a list of DLSw capable routers
   and their status (active/inactive). Before Data Link Switching can
   occur between two routers, they must establish two TCP connections
   between them. These connections are treated as half duplex data
   pipes. A Data Link Switch will listen for incoming connections on its
   Read Port (2065), and initiate outgoing connections on its Write Port
   (2067).  Each Switch is responsible for initiating one of the two TCP
   connections.  After the TCP connections are established, SSP messages
   are exchanged to establish the capabilities of the two Data Link
   Switches.  Once the exchange is complete, the DLSw will employ SSP
   control messages to establish end-to-end circuits over the transport
   connection.  Within the transport connection, DLSw SSP messages are
   exchanged.  The message formats and types for these SSP messages are
   documented in the following sections.

In section 7.6.7 (TCP Connections Control Vector), I would modify the
third paragraph:

   If TCP Connections CV values agree and the number of connections is
   one, then the DLSw with the higher IP address must tear down the TCP
   connections on its local port 2065. This connection is torn down
   after a CAPEX response has been both sent and received.  After this
   point, the remaining tcp connection is used to exchange data in both
   directions.

Can you include these changes in your document, and circulate them when
(if?)
you decide to mail out proposed changes?

Thanx,
Doug Wolff
(408) 764-8186

---

From: Paul Brittain <[email-masked]>
Date: Tue, 16 Jul 1996 11:21:10 +0100

>-	The RII bit in MAC addresses received from the LAN must be set to
>zero before forwarding in a SSP message.  This requirement aims to
>avoid ambiguity of circuit IDs.
>
>-	The first flow-control ack (FCACK) does not have to be returned on
>the REACH_ACK even if the ICR_cs carried the FCIND bit.  However it
>should be returned on the first SSP frame flowing for that circuit
>after the REACH_ACK.
>
>-	HALT reason codes should be added to the HALT_DL and HALT_DL_NOACK
>SSP messages.
>
>drop to a single TCP pipe (see attached mail from Doug Wolff for
>further details).
>
>Most of the time at AIW 9 was spent discussing the scalability
>proposal.  This lengthy series of discussions came up with a number of
>major points, and some more minor editorial issues.  The editorial
>points have not been listed in full here for sake of brevity.  Dave
>Bryant has already posted the updated scalability document.
>
>-	Section 2 will need changing to incorporate other work in the RIG
>(see below).  This activity will be deferred to the CP draft for
>closure once the full set of work forming the next version is complete.
>
>scalability enhancements (though all "v2 compliant" implementations
>must be capable of using the multicast enhancements).
>
>pip is already up, otherwise Unicast should be used.  Also, clarify
>that it may be necessary to send multicast to and TCP explorer frames
>in the migration case.
>
>-	The issue of reducing the SSP frame header size for Netbios frames
>was raised, but postponed for future work.  Proposals are welcomed on
>this topic.
>
>------------------------------------------------------------------------
>------------------------
>ATTACHMENTS:
>=============
>
>
>In section 3 (transport connections), I would modify the paragraph
>below the
>figure as follows:
>